Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000049_owner-urn-ietf _Tue Nov 5 23:27:46 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04188 for urn-ietf-out; Tue, 5 Nov 1996 23:27:46 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04181 for <[e-mail]>; Tue, 5 Nov 1996 23:27:42 -0500
Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA07683  (mail destined for [e-mail]); Tue, 5 Nov 96 23:27:40 -0500
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
          id XAA28250; Tue, 5 Nov 1996 23:27:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.7 5/3/96
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Bob Briscoe <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [URN] Resolution Services (N2L etc)
In-Reply-To: Your message of "Tue, 05 Nov 1996 10:01:53 GMT."
             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 05 Nov 1996 23:27:21 -0500
Sender: [e-mail]
Precedence: bulk
Reply-To: Keith Moore <[e-mail]>
Errors-To: [e-mail]

> 1.2 It strikes me that specifying available service requests (N2L, N2R etc)
> should not be the job of DNS or any URN resolution mechanism. You are adding
> metadata about the address that the name resolves to (i.e. allowed methods).
> NAPTR should simply get you to the place you asked for by mapping names to
> addresses.

Not clear.  DNS is the place to store name-to-IP-address bindings.  If
the different services (methods) are at different IP-addresses, the
mappings between the names of the machines where the services reside,
and their IP addresses will be managed by DNS.  And there's
potentially a big efficiency win to having the name-to-service mapping
lookup occur as a side-effect of an lookup that returns NAPTR records
with an /s flag.

> Other systems  (service discovery or navigation) should allow you to
> determine what you *should* ask for from the address once you get it, and
> once you have the address each protocol scheme might provide a well-known
> method for querying what methods you *can* do if that is what the scheme
> needs (e.g. HTTP/1.1 OPTIONS method).

Only if all possible methods for a service are available at every
service location.  You don't want to have to ask each service location
which methods are available at that server.

> IOW, the client should already know
> what it is going to do with the address it gets out of the URN service, or
> if it doesn't it should be prepared to find out.

The client knows what it wants to do.  But how the client does what it
wants to do may depend on what services are available.  If there are
multiple resolution services available for a particular chunk of name
space, it might be that several of them will do what the client wants.
For example, if all a client wants is a URL, N2L might be more
efficient than N2C.

> OK, it may be *easier* to hack it this way, but that's not the point. You
> are embedding a duplication of meta-information in DNS which will always be
> prone to being out of date, unreliable, etc. Especially if the world moves
> to be much more dynamic in this area in the decades you envisage this
> lasting. More importantly, this information potentially has a different TTL
> than the address itself, so it will break your caching.

I don't see what the problem is.  DNS can specify TTLs on a
per-resource-record basis.

At any rate, we should view the use of DNS for resolution as a
short-term experiment rather than a long-term solution.  Viewed in
that context, it's not important that we get every little detail
right.

Keith